A significant advantage of a Java system is that the reclamation of memory is managed automatically by a garbage collector and programmers do not need to release the memory by calling a function. The memory management in Java refers to the allocations and releases of objects. In Java, it is required that memory space is requested for each object through programs. And the spaces are allocated for all the objects in the heap memory and the releases of objects are decided and performed by the garbage collector. Given that, in Java, the allocation of memory is performed by programs and the release of the memory is performed by the garbage collector. In this way, the programmers do not need to worry about the problem of the release of memory.
However, a Java program may inadvertently maintain references to some objects which are no longer used, preventing the garbage collector in the Java system from reclaiming the memory space occupied by these objects, which causes so-called “Memory Leak”. Memory leak will lead to degraded performance of the Java system, and at worst to programs being incapable of running or the system crashing. For example, an investigation of customers of IBM J2EE electronic business software revealed that production systems frequently crash because of memory leaks. Thus, it becomes very important to diagnose the memory leaks in Java systems, i.e. finding out the related classes, and methods, etc.
In the prior art, there are several memory leak-related methods as follows:
1. The first method: memory accounting and controlling for tasks, which may prevent one task from exhausting the whole memory during runtime. In a multitask virtual machine (MVM), each task has a guaranteed amount of memory. A Kaffe operating system (KaffeOS) accounts for CPU and memory on a per-process basis to limit the consumption. By accounting and controlling memory consumption, the task or process with leaking logic cannot monopolize the whole heap memory even in the presence of memory leaks. This method may improve the availability of running applications in the presence of memory leaks, but it can neither identify the reason for a memory leak nor help the user find out the memory leak-related source code. The details of the above method and KaffeOS are detailed in “Multitasking without compromise: a virtual machine evolution”, published by Czajkowski, G. and Dayn es, L., Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA'01), November 2001; and “Processes in KaffeOS: Isolation, resource management, and sharing in Java”, published by G. Back, W. Hsieh, and J. Lepreau, Proceedings of the Fourth Symposium on Operating System Design and Implementation (OSDI'2000), San Diego, Calif., USA, 2000.
2. The second method: static or profile-based analysis on source code according to some characteristics and rules to find out potential memory leak. Now, developers have conducted a lot of research on such method. For example, please refer to: “Automatic removal of array memory leaks in Java”, published by R. Shaham, E. K. Kolodner, and M. Sagiv, D. A. Watt, Editor, Compiler Construction, 9th International Conference, Volume 1781 of Lecture Notes in Computer Science, pages 50-66, Berlin, Germany, March 2000; and “Low-overhead memory leak detection using adaptive statistical profiling”, published by T. Chilimbi and M. Hauswirth, Proceedings of the Symposium on Architectural Support for Programming Languages and Operating Systems (ASPLOS), October 2004.
However, memory leak in Java is actually semantic related. Accordingly, the definitions of characteristics and rules are quite hard, and improper definitions will result in inaccurate reports. Further, without stressing on the temporal order of method object invocations, it is hard to determine whether a variable refers to a leaked object or not.
3. The third method: runtime information-based approaches, which analyzes the snapshots of heap memory to pick out candidates of leaked objects. The details may be referred to: “LeakBot: An Automated and Lightweight Tool for Diagnosing Memory Leaks in Large Java Applications”, published by Nick Mitchell and Gary Sevitsky, European Conference on Object-oriented Computing (ECOOP), July 2003. However, such approaches tend to yield large amounts of low-level information about individual objects that require a lot of analysis time and knowledge of applications, and cannot help the user find out the memory leak-related source code.